home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001212_wei@xcf.berkeley.edu _Sat May 29 01:48:09 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <wei@xcf.berkeley.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA21612; Sat, 29 May 93 01:48:09 MET DST
  4. Received: from xcf.Berkeley.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA10705; Sat, 29 May 1993 02:09:39 +0200
  6. Received: by xcf.Berkeley.EDU (5.65/XCF-1.34)
  7.     id AA19076; Fri, 28 May 93 17:10:03 -0700
  8. Date: Fri, 28 May 93 17:10:03 -0700
  9. From: wei@xcf.berkeley.edu (Pei Y. Wei)
  10. Message-Id: <9305290010.AA19076@xcf.Berkeley.EDU>
  11. To: hoesel@chem.rug.nl, www-talk@nxoc01.cern.ch
  12. Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
  13.  
  14. Something like ISMAP is what you'd want for applications like, say,
  15. a cartographic service, where the user could select an area (mouseDown
  16. for x0,y0, mouseUp for x1,y1), and have the selected area sent to the
  17. server, which will return the image (or vectors) for the new area.
  18. And in the future (with common availability of 3D pointing devices :-) 
  19. this should be easily extensible to 3D-space selection. 
  20.  
  21. This sort of application would be tedious (probably impossible for 3D case)
  22. and clumsy to implement with the area-overlay-buttons approach.
  23.  
  24. However, one could think of lots of other applications where it would 
  25. be easier and more appropriate to use area-overlay-buttons. Just look at
  26. the numerous HyperCard stackwares that use ``invisible fields'' to
  27. implement highly neat effects. This approach, however hard-coded but
  28. no more than ``HREF='' is hard-coded, has the benefits of no necessary
  29. dependence on a server.
  30.  
  31. So, as I've indicated to Tony before off www-talk, I feel that both are
  32. necessary and have their respective uses. In HMML (my working version 
  33. anyway-- have to sync it with Dave), there's a FIGURE tag which could 
  34. be used in the following ways (fictitious services):
  35.  
  36. As with <IMG>:
  37.  
  38.     <FIGURE SRC="http://smithsonian.gov/gallery/irises.gif" 
  39.         TYPE="image/gif">
  40.  
  41. Includes a figure specific caption:
  42.  
  43.     <FIGURE SRC="http://smithsonian.gov/gallery/irises.gif" 
  44.         TYPE="image/gif">
  45.       <FIGCAP>Irises, 1889, Vincent Van Gogh</FIGCAP>
  46.     </FIGURE>
  47.  
  48. Includes the actual figure data:
  49.  
  50.     <FIGURE TYPE="application/tex">
  51.       <FIGDATA>
  52.       ...the actual TeX notation...
  53.       </FIGDATA>
  54.     </FIGURE>
  55.  
  56. An example of ISMAP usage -- server generates and returns the selected
  57. topographic region in postscript form:
  58.  
  59.     <FIGURE SRC="http://usgs.gov/maps/topographic.ps"
  60.         TYPE="application/postscript"
  61.         ISMAP>
  62.  
  63. An example of invisible/see-thru buttons overlaying an image -- face.gif
  64. is visible, and has two invisible area oriented anchors pointing to 
  65. eyes.gif and mouth.gif respectively. Probably unnecessary, but WIDTH & 
  66. HEIGHT could be specified to handle scaling. Also, perhaps <FIGA> should
  67. simply be <A>. :
  68.  
  69.     <FIGURE SRC="http://sesame-st.org/whatis/face.gif" TYPE="image/gif"
  70.         WIDTH=100 HEIGHT=100>
  71.       <FIGA HREF="http://sesame-st.org/whatis/eyes.gif" TYPE="image/gif"
  72.         x0=20 y0=10 x1=80 y1=30>
  73.       <FIGA HREF="http://sesame-st.org/whatis/mouth.gif" TYPE="image/gif"
  74.         x0=40 y0=70 x1=60 y1=80>
  75.       <FIGCAP>Spy a face</FIGCAP>
  76.     </FIGURE>
  77.  
  78.  
  79. I would, and I'm sure Dave would, appreciate constructive arguments 
  80. for or against <FIGURE> as described above. It's of course still very 
  81. open to suggestions at this point.
  82.  
  83.  
  84. Pei Y. Wei
  85. O'Reilly & Associates
  86. Digital Media Group
  87. pei@ora.com